Assembly language code is used in a variety of applications. In order to generate an executable image from assembly language code, a conventional assembler is typically used. FIG. 1 depicts a conventional assembler 10. The conventional assembler 10 includes a parser/lexer 12 for reading in assembly language code and a code generator 14 for generating the executable image. Assembler 10 sequentially invokes parser/lexer 12 followed by code generator 14.
FIG. 2 is a high-level flow chart depicting a conventional method 50 for generating an executable image from assembly language code using the conventional assembler 10. Resources to meet needs within the code are manually assigned by the programmer, via step 52. The assembly language code is then assembled by 10, via step 54. An executable image is thus provided. The executable image from step 54 is analyzed for problems including resource conflicts, via step 56. If resource conflicts do exist, then step 58 forces another manual assignment of resources in step 52. The cycle of steps 52, 54, 56 and 58 continues until no resource conflicts or other defects are found, thus realizing the final executable image.
One of ordinary skill in the art will readily recognize that the method 50 may be time-consuming and relatively difficult to implement. In particular, the programmer must manage the resources to be used by the code manually, and debug resource conflicts in the executable image's run time environment. The most common solution to this problem is to move to a higher-level programming language such as ‘C’ or ‘BASIC’. However, the programmer must surrender the detailed control provided by assembly language to gain the resource management provided by a higher-level language.
For those programmers unwilling to sacrifice the detailed control of the processor provided by assembly language programming, what is needed is a system and method for integrating processor resource management into assembly language. The present invention addresses such a need.